Integration of currently existing non-compatible system/software components is a necessary reality. Presently, there are thousands of existing computer and/or software systems (e.g., legacy systems) that were designed to support information exchange with, at most, a defined group of systems. Economic factors make it necessary to continue to use these systems for some period of time, yet in many cases it is desirable to integrate these defined groups of systems with a number of other systems outside of their existing integration capabilities. Today's global networking/communications capability provides a data path between many of existing systems, but it has proven expensive and time-consuming to modify the software and data structures of these systems, so as to provide complete integration.
Over the last ten years many mechanisms for integration have been offered for supporting different aspects of integration and interoperability. Work-flow mechanisms, for example, have been built to support limited control integration (e.g., linear process execution). However, work-flow systems rely on sequential execution, and are somewhat impractical for systems based on an event-driven paradigm. Most approaches to achieve integration that have been offered to date either only work for systems built from the beginning around their design paradigm or software structure, or require expensive and time-consuming re-engineering of the existing system. Therefore, a technique to provide a quick and inexpensive integration solution of existing computer/software systems would be highly desirable in the business community at large.
In many cases, achieving interoperability between two or more computer/software components is significantly complex. Therefore, integration connector topologies have been developed to facilitate the integration process. A typical integration connector topology includes developing a plurality of custom connectors at a given component, where each component is customized to interact unilaterally with a “mating” custom connector in another component/system. Therefore, each component/system in the integration process needs a plurality of customized connectors. Development of these customized connectors requires knowledge of the resources/data required and provided by each of the component/system being integrated. In order for those connectors to be written, changes of the software in the existing components/systems and a direct connection among those components/systems is typically required.
Another connector topology includes employing a “middleware component” (e.g., CORBA, many others) to abstract the actual interfaces of the other systems and/or their location. Middleware connectors can be developed only needing knowledge about the middleware language/mechanism and the resources/data it needs or provides. However, the numbers of connectors may still be the same as the custom connector topology, and the extent of the effort required to re-engineer an existing software system to utilize such a middleware component can be prohibitive.